Memory management has become a high priority in modern computing systems. Current memory management systems have the capability to dynamically allocate and deallocate memory. Many memory management systems utilize some type of a memory manager to manage memory operations, such as memory allocation and deallocation operations. For example, a memory manager can be used to free data from memory (e.g. a memory block) and to dedicate memory for use by a calling application. As part of a memory allocation operation, a memory manager may locate free memory and return a marker to a calling program which delineates the allocated memory. Calling programs typically include diagnostic tools which verify that memory distributed to the calling program is equal to an amount of memory that the program is aware of.
When finished with the memory, a calling program may return the allocated memory to the memory manager. Thereafter, the memory manager may free the memory. However, problems arise when a block of memory is not returned to the memory manager, such as when the calling application loses track of a memory allocation. This scenario is often referred to as a “memory leak” and is generally associated with some type of software bug or error. Some current memory management methods attempt to detect memory leaks by intentionally making each allocated block larger than asked for, and storing memory tracking data in the extra space of each allocated block. This adds overhead to the system. Such a method is commonly implemented for debug versions of a product, but not for release versions. Consequently, such an implementation can result in discrepancies between the behavior of the debug version and a ship version of the product, which can potentially hide bugs.